projects/surf-liquid/index.js (1)

56-67: Consider separating staking into its own export.

SURF staking and CreatorBid subscriptions are currently merged into the tvl function. DefiLlama convention typically separates protocol token staking into a dedicated staking export. This provides clearer metrics and matches the test output showing distinct base ($239k) and base-staking ($31k) values.

♻️ Suggested refactor to separate staking

 async function tvl(api) {
   const tokensAndOwners = [];
   // ... V2 and V3 vault logic ...
   await api.sumTokens({ tokensAndOwners });
-
-  // SURF staking contract
-  const totalStaked = await api.call({ abi: "uint256:totalStaked", target: SURF_STAKING });
-  api.add(SURF_TOKEN, totalStaked);
-
-  // CreatorBid SURF subscriptions (SURF locked in the token contract)
-  const subscribed = await api.call({
-    abi: "function balanceOf(address) view returns (uint256)",
-    target: SURF_TOKEN,
-    params: [SURF_TOKEN],
-  });
-  api.add(SURF_TOKEN, subscribed);
 }

+async function staking(api) {
+  // SURF staking contract
+  const totalStaked = await api.call({ abi: "uint256:totalStaked", target: SURF_STAKING });
+  api.add(SURF_TOKEN, totalStaked);
+
+  // CreatorBid SURF subscriptions (SURF locked in the token contract)
+  const subscribed = await api.call({
+    abi: "function balanceOf(address) view returns (uint256)",
+    target: SURF_TOKEN,
+    params: [SURF_TOKEN],
+  });
+  api.add(SURF_TOKEN, subscribed);
+}

 module.exports = {
   // ...
   base: {
     tvl,
+    staking,
   },
 };

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@projects/surf-liquid/index.js` around lines 56 - 67, Split the SURF staking
logic out of the tvl function into a dedicated staking export: move the call
that reads totalStaked (the api.call with abi "uint256:totalStaked" targeting
SURF_STAKING) and the corresponding api.add(SURF_TOKEN, totalStaked) into a new
exported async function named staking (or export const staking = { tvl: ... }
per repo convention) that returns the staking balances; keep the existing
CreatorBid subscription code (the balanceOf call using SURF_TOKEN as target and
params [SURF_TOKEN] and its api.add) inside tvl. Ensure the new staking export
uses the same api instance pattern and is exported alongside tvl so
tests/reporting show separate base and base-staking values.

projects/surf-liquid/index.js (2)

71-77: ⚠️ Potential issue | 🟠 Major

Mark wrapped/downstream TVL explicitly in adapter metadata.

base.tvl sums Morpho ERC-4626 share balances held by Surf vaults, which is wrapped/downstream exposure and can overlap with underlying protocol TVL. Add doublecounted: true and misrepresentedTokens: true (or unwrap to underlying instead).

🏷️ Proposed metadata update

 module.exports = {
   methodology: "TVL counts Morpho vault deposits across V2 and V3 Surf Liquid vaults. Staking includes SURF staked and SURF subscriptions.",
+  doublecounted: true,
+  misrepresentedTokens: true,
   hallmarks: [["2025-11-30", "V3 factory launched"]],
   base: {
     tvl,
     staking,
   },
 };

Based on learnings, the Royco v2 adapter marks vault-in-vault accounting as doublecounted: true, and AFI marks raw vault-share reporting as misrepresentedTokens: true.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@projects/surf-liquid/index.js` around lines 71 - 77, The adapter metadata
currently exports module.exports with base: { tvl, staking } but does not mark
that base.tvl reports wrapped/downstream Morpho ERC-4626 share balances; update
the exported metadata to explicitly flag this by adding doublecounted: true and
misrepresentedTokens: true (or alternatively unwrap the vault shares to
underlying assets) so consumers know the TVL may overlap with underlying
protocols; locate the module.exports block (symbols: module.exports, base, tvl,
staking) and add those two boolean flags to the metadata object.

---

25-27: ⚠️ Potential issue | 🟡 Minor

Harden V2 pair validation before sumTokens.

At Line 26, the guard still only checks v2MorphoVaults[i] !== ZERO_ADDR. If v2Owners[i] or v2MorphoVaults[i] is falsy, an invalid [token, owner] pair can still be pushed.

🛡️ Proposed fix

   for (let i = 0; i < v2Owners.length; i++) {
-    if (v2MorphoVaults[i] !== ZERO_ADDR) {
+    if (v2Owners[i] && v2Owners[i] !== ZERO_ADDR && v2MorphoVaults[i] && v2MorphoVaults[i] !== ZERO_ADDR) {
       tokensAndOwners.push([v2MorphoVaults[i], v2Owners[i]]);
     }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@projects/surf-liquid/index.js` around lines 25 - 27, The loop that builds
tokensAndOwners currently only checks v2MorphoVaults[i] !== ZERO_ADDR and can
push invalid pairs when v2Owners[i] or v2MorphoVaults[i] is falsy; update the
guard in the loop that iterates over v2Owners to ensure both v2MorphoVaults[i]
is truthy and not ZERO_ADDR and v2Owners[i] is truthy before pushing into
tokensAndOwners so sumTokens receives only valid [token, owner] tuples (refer to
v2Owners, v2MorphoVaults, ZERO_ADDR, tokensAndOwners and the code path that
calls sumTokens).

projects/surf-liquid/index.js (1)

37-37: Consider documenting the hardcoded fromBlock.

The magic number 38856207 should have a brief inline comment explaining it's the V3 factory deployment block, improving maintainability for future developers.

-    fromBlock: 38856207,
+    fromBlock: 38856207, // V3 factory deployment block

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@projects/surf-liquid/index.js` at line 37, The literal 38856207 assigned to
fromBlock is a magic number; add a brief inline comment next to the fromBlock
assignment (the "fromBlock" property containing 38856207) stating that this is
the V3 factory deployment block (include network and approximate date if known)
so future maintainers understand why it is hardcoded and can update it safely.